![[レポート]Dive deep into Amazon EKS fleet management #KUB303 #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
[レポート]Dive deep into Amazon EKS fleet management #KUB303 #AWSreInvent
2024.12.04ArgoCD などを活用して 大量の Kubernetes クラスターを効率よく管理する方法について学ぶ、内容盛りだくさんな Workshop に参加してきました！
セッション概要
タイトル
KUB303 | Dive deep into Amazon EKS fleet management
説明
Elevate your Amazon EKS skills with this hands-on workshop designed for experienced builders. Learn how to create a unified internal developer platform for Amazon EKS clusters across environments using GitOps principles. Hone your skills in multi-cluster resource configuration, drift detection, and lifecycle management while ensuring compliance and security. Gain practical skills in implementing platform engineering for consistent resource states, enforcing policies across clusters, and centralizing logging, metrics, monitoring, and access control. Equip yourself with cutting-edge strategies to efficiently manage and secure your Amazon EKS fleet at scale. You must bring your laptop to participate.
スピーカー
Carlos Santana, Sr. Specialist Solutions Architect, AWS
Sebastien Allamand, Sr. Specialist Solutions Architect, AWS
Workshop としては下記になります。
セッションに参加していないが、興味がある方はやってみて下さい！
ただ、複数 EKS クラスターを扱うので意図しない課金には気を付けて下さい。
公開されたソースコードは下記になります。
講義
タイトルは「Dive deep into Amazon EKS fleet management」と少し抽象度が高いですが、ArgoCD を用いた GitOps が話題の中心でした。
EKS の採用が増えて、クラスター数が増えている。デプロイが大変だし、それぞれのクラスターのバージョン管理も大変。
この辺りを解決するために、GitOps が良いという論調でした。
必ずしも GitOps でなくともデプロイ自動化までは可能かと思いますが、そちらの方がより効率的に複数クラスターを管理しやすいという話。
また、Platform Engineering 専門のチームが明確に存在していて、アプリケーションの管理者と EKS クラスターの管理者が別れている前提です。
ちょっと画質が荒いですが、GitOps もメリットとして下記 4 つが挙げられていました。
Desired State is expressed declaratively
あるべき姿が明確に宣言されているという話ですね。
Git 管理されたソースコードを元にリソースをデプロイするので、ソースコードを見れば現在の状態が明確にわかりやすいです。
Git のリポジトリが Single Source of Truth になるという話。
Persisted in an immutable & version stored
Git リポジトリの変更を通してのみリソースが変更されるので、各状態をバージョン管理できるし、各デプロイはイミュータブルになります。
Agent automatically pull desired state
各クラスターにデプロイされたエージェントが Git 側の状態を確認して、pull 型のデプロイを行う形になります。
デプロイ用にインバウンドのポート開けをしなくて良いので、セキュリティを高めることに繋がります。
Agents Continuously Observe and reconcile
エージェントが継続的に Git の状態を監視して、あるべき状態に持っていくので、デプロイ失敗などで環境間の一貫性が崩れることが無いという話。
たしかに、ネットワーク起因などのデプロイ失敗には強くなりますね。
Argo CD セットアップ
ハンズオンを始めていきます。
今回扱うのは hub-spoke トポロジーのマルチクラスター環境です。
中央の EKS クラスターに存在する ArgoCD が、各クラスターのコンポーネントを集中的に管理します。
また、各ワークロードを配置するクラスターには addons と呼ばれる共通で必要になるコンポーネント(AWS Load Balancer Controller や EBS CSI driver など)と、workloads 専用のコンポーネントがそれぞれデプロイされます。
Multi-Cluster centralized hub-spoke topology
さっそく Argo CD を触っていくのですが、用意された VS Code Server 上でコマンドを打つと URL と認証情報を払い出してくれるようになっています。
セットアップが非常に簡単で、作業開始して 1 分立たずに ArgoCD の画面を確認できました。
ワークショップの内容もコードも公開されているとはいえ、本当に Workshop 素晴らしいなと思いました。
QA 対応してくれる方も多かったですし、それなりに難しい内容なのに詰まる部分がほとんど無かったです。
最初からこのように ArgoCD の画面を確認できます。
ということで、作業開始です。
本番用のクラスターに Argo CD をセットアップして、各コンポーネントをデプロイする内容になります。
Hub 用のクラスターと、Staging 用のクラスターは既にセットアップ済みです。
Argo CD が扱う認証情報を格納するための Secret Manager を作成します。
aws secretsmanager get-secret-value --secret-id fleet-hub-cluster/fleet-spoke-prod --query SecretString --output text | jq .
本番用クラスターをフリートに追加します。
どのクラスターがメンバーになるかといった設定も、Git 管理されます。
mkdir $GITOPS_DIR/fleet/members/fleet-spoke-prod
cat > $GITOPS_DIR/fleet/members/fleet-spoke-prod/values.yaml << 'EOF'
tenant: "tenant1"
environment: "prod"
clusterName: "fleet-spoke-prod"
secretManagerSecretName: "fleet-hub-cluster/fleet-spoke-prod"
EOF
git -C $GITOPS_DIR/fleet status
git -C $GITOPS_DIR/fleet add .
git -C $GITOPS_DIR/fleet commit -m "add production cluster fleet member"
git -C $GITOPS_DIR/fleet push
本番環境にアドオンから追加していきます。
mkdir $GITOPS_DIR/addons/clusters/fleet-spoke-prod
cp -r $WORKSHOP_DIR/gitops/solutions/module-platform/addons/clusters/fleet-spoke-prod/* $GITOPS_DIR/addons/clusters/fleet-spoke-prod/
git -C $GITOPS_DIR/addons status
git -C $GITOPS_DIR/addons add .
git -C $GITOPS_DIR/addons commit -m "add addons for production cluster"
git -C $GITOPS_DIR/addons push
ちなみに、アドオンとして共通でインストールされるコンポーネントは下記です。
- adot-collector
- aws-ebs-csi-driver
- aws-load-balancer-controller
- cert-manager
- cni-metrics-helper
- cw-prometheus
- karpenter
- kube-state-metrics
- kyverno
- kyverno-policies
- kyverno-policy-reporter
- metrics-server
- opentelemetry-operator
- prometheus-node-exporter
多いですね...
環境ごとに手作業でセットアップしていったら、何時間かかることか...
それがものの 10 分程度でセットアップされます。
ちなみに、これらのリソースの内、EBS CSI driver、AWS LoadBalancer Controller、Karpenter 辺りは先日発表された Auto Mode を使えば EKS 側に管理してもらうことができます。
ここまで Platform Engineering チームがセットアップしてくれるならまだしも、そうでないなら Auto Mode 最高だなと改めて思いました。
続いて、workload 用のコンポーネントを追加します。
これも Git 操作して、Argo CD 側で Sync するだけです。
cp -r $WORKSHOP_DIR/gitops/solutions/module-platform/platform/teams/* $GITOPS_DIR/platform/teams/
git -C $GITOPS_DIR/platform status
git -C $GITOPS_DIR/platform add .
git -C $GITOPS_DIR/platform commit -m "add production namespaces for teams"
git -C $GITOPS_DIR/platform push
ArgoCD が頑張って sync してくれている状態を眺めているだけ。
待っていると、Web アプリにデプロイできるようになりました！
ArgoCD 最高！！
可視化
本 Workshop はここでは終わらず、可視化の話に移ります。
いわゆるリソース監視に留まらず、ArgoCD のデプロイ状況や Kubernetes バージョン状況まで可視化していきます。
そうなってくると自前でダッシュボードを組む必要があるので、諸々構築していきます。
QuickSight 周りの権限付与だけマネジメントコンソールから実施します。
その他のリソースはコマンド一発叩くだけで作ってくれました。
deploy_fleet_dashboard
ということで、クラスターバージョン管理用のダッシュボードから見ていきます。
各クラスターのバージョンから、EOS まで丸わかりですね。
ArgoCD のデプロイ状況可視化用のダッシュボードも見ていきます。
Sync が失敗していないか、どのようなリソースがデプロイされているかまで、綺麗に可視化されています。
リソース監視用のダッシュボードもみます。
こちらは Container Insights with enhanced observability for Amazon EKS のダッシュボードを見る形ですね。
これです。
CoreDNS 管理用の CloudWatch ダッシュボードです。
Karpenter 管理用の CloudWatch ダッシュボードです。
VPC CNI driver 管理用の CloudWatch ダッシュボードです。
でも、この辺りは Auto Mode なら管理しなくて良いのか！最高！！(本日 2 度目)
セキュリティ強化
ここでも終わらず、ポリシーベースでセキュリティを強化する話になります。
たったの 2 時間で何から何まで学ばせてくれる最高の workshop です。
組織のセキュリティポリシーに従って Pod が実行されているかを制御するために Pod Security Admission（PSA）および Pod Security Standards (PSS) を設定しようという話です。
PSS は下記 3 つのセキュリティポリシーとそれらに属するコントロール(チェック項目)を定義しています。
- Privileged (unsecure)
- Baseline (secure)
- Restricted (highly secure)
PSA は PSS の実装というべき物であり、Pod にセキュリティ標準を適用する方法を提供します。PSA 側の設定によって、実際に Pod の起動をブロックするか、警告を出すだけかなどを選ぶことができます。
- Enforce (rejects pod creation if policy violations are detected)
- Audit (logs policy violations but accepts pod creation)
- Warn (behaves like Enforce but also triggers a user-facing warning)
PSA だと同一名前空間の全ての Pod に同じポリシーが当たってしまうので、より柔軟に制御したい場合は Kyverno などのツールを利用すると良いということでした。
このページはとても上手くまとまっていたので、気になる方は確認してみて下さい。
また、Kyverno の Reporter を利用することで、ポリシー違反を簡単に可視化することが可能です。
さっそくダッシュボードを見ていきます。
Baseline レベルでは、特に違反している項目はありませんでした。
より厳しい Restricted レベルで確認すると、複数違反が出てます。
違反項目は詳細も確認可能です。
Kyverno Policy reporter を Security Hub と連携することで、AWS 側でポリシー違反を確認することもできます。
AWS インフラ側の Security Hub 違反と合わせて一元的に見れるのは良いですね。
取り込んでしまえば、Security Hub の findings として扱えるので通知などもまとめて作りこみやすいですね。
まとめ
大量のクラスターを効率的に管理するエッセンスが詰まった大満足のハンズオンでした！
ソースコードなども公開されているので、クラスター管理に困っている方は是非確認してみて下さい。
